Modern computing devices typically include a main storage device (e.g., a hard disk drive or a solid state drive) that stores operating system (OS) files and user files. According to one common configuration, the storage device is segmented into at least two partitions: 1) a “host” partition that stores both the OS files and the user files, and 2) a “boot” partition that stores files used to boot the OS when the computing device is powered-on. In this configuration, a basic input/output (BIOS) system of the computing device, when powered-on, reads and then executes the files in the boot partition to cause the OS files stored on the host partition to properly initialize and execute on the computing device.
In some cases, the host partition and/or the boot partition can become corrupted, for example, when a user interrupts the computing device during a shutdown procedure. When this occurs, the computing device cannot properly boot during the next power-on, thereby rendering the computing device inoperable. One common approach used to recover such an inoperable computing device involves utilizing an optical disc drive included in the computing device. In particular, the user inserts into the optical disc drive a compact disc (CD) that includes a “recovery” OS that the computing device can read from the CD and execute when the inoperable computing device is powered-on. Typically, the recovery OS enables the user to perform a variety of tasks to repair the computing device, which include identifying and fixing the corrupted host/boot partition files or enacting a complete deletion and reinstallation of the OS.
Although the optical disc drives provide a reliable solution to the foregoing problem, they are nonetheless being phased-out for a variety of reasons, which include the pursuit of effecting overall decreases in the number of moving parts, weight and power consumption of computing devices. To address this change, engineers have established a new technique for enabling users to recover inoperable computing devices that do not include optical disc drives. One popular technique involves storing within the boot partition a version of the recovery OS described above. In this way, the user can choose, during a power-on of the computing device, to load the recovery OS stored in the boot partition and perform one of the repair tasks described above. Notably, the boot partition is, in most cases, sized at or around the minimum amount of space required to store the recovery OS/OS boot files in order to maximize the amount of free storage space available to other partitions on the storage device, e.g., the host partition.
Oftentimes, it is desirable to replace the recovery OS with a newer, updated version that enhances the repair process of the computing device in the event that it becomes inoperable. As is typical with most software updates, the updated version of the recovery OS will likely be larger in size than any current recovery OS stored in the boot partition. Considering that the boot partition is sized to fit only the recovery OS stored therein, the boot partition must be first be resized in order to accommodate the updated, larger version of the recovery OS. However, several limitations exist with respect to resizing partitions. For example, some file system limitations dictate that a partition can be “grown” (i.e., increased in size) from the end of the partition, but cannot be grown from the start of the partition. This limitation makes increasing the size of the boot partition problematic when the end of the boot partition abuts the start of another partition. Another example file system limitation, due to the lack of safety of an overlapping block copy process, dictates that the size of a partition can only be increased by a size greater than 2*N where N is the current size of the partition, which results in wasteful consumption of free storage space within the storage device when the additional amount of space required to store the updated recovery OS is only marginal.
The limitations described above have forced developers into implementing recovery OS upgrade processes that are highly susceptible to failure, e.g., deleting the existing boot partition and then regenerating a new boot partition of an increased size. Notably, if the power supply to the computing device were disconnected immediately after deletion of the boot partition, then the storage device is left void of a boot partition and cannot execute a host OS boot or a recovery OS boot when restarted. Such a scenario—combined with the absence of an optical disc drive from the computing device—results in the computing device being “bricked” and totally inoperable, with no route available for a software-based recovery.